組織全体で技術スタックを統一している事例を調べてみた
CX事業本部デリバリー部アーキテクトチームの吉川@広島です。
自分は案件において、フロントエンドCloudFront+S3+React、バックエンドAPIGW（or AppSync）+Lambda+Node.js（TypeScript）+DynamoDB、IaCはCDK、CI/CDはGitHub Actionsという技術スタックで携わることが多いです。
他方、社内の案件全体としてはフロントエンドをNext.jsにする、バックエンド言語にGoを採用する、バックエンドアプリをECSに置く、DBにRDSを採用する、IaCはTerraform、CI/CDはAWS Codeシリーズ……など、技術選択が非常に多岐に渡っていると思います（採用サイトを見つつ）。この体制のメリットとしては、社内で幅広く技術に関するノウハウを持つことができるし、顧客に対しても多様なソリューションを展開することができるという点がありそうに思います。
そんな中で「じゃあ、逆に組織全体で採用技術スタックを統一していくという道はアリなんだろうか？」という方面に関心が出てきたため、
- どんな会社が
- どんな理由で
- どんな技術に統一しているのか
の事例を調べてみました。
執筆者個人が収集した情報であり、必ずしも正確に最新情報を反映できていない可能性がある点ご留意ください。できるだけ認識齟齬を抑えるべく、出典の書籍出版年もしくはインターネット記事執筆年を併記しています。
Google社: 言語からライブラリまで統一 (2021時点情報)
実のところ、本件を調べてみようと思ったのはオライリー出版の『Googleのソフトウェアエンジニアリング』（2021）を読んでいて少し驚いたからです。
例えば、何年も前にGoogleは、新規のJavaテスト内で使用されるべき唯一のモッキングフレームワークとしてMockitoの利用を義務化し、新規のテストで他のモッキングフレームワークを使用することを禁じた。（『12.3.4 テストインフラストラクチャーを定義する』）
（特に何の根拠もないのですが）個人的にGoogle社はソフトウェアエンジニアの裁量が非常に大きいイメージを持っており、チームメンバーによって生産性を発揮できるライブラリを各々選定しているのかなと思っていたためにやや衝撃がありました。
上記の命令に社内ではある程度反発があったようですが、
だが今日では皆が、この命令は社内のテストの理解と扱いを簡単にした好手だったと考えている。（『12.3.4 テストインフラストラクチャーを定義する』）
のように受け入れられたとあります。
こういった意思決定は、
どんなエンジニアでも、コードベースの馴染みのない部分に突然前入っていったとしても、一貫性というものが保たれていることで、相当素早く作業に移れるのだ。だがツールは同じ、テクニックは同じ、ライブラリは同じ、そして全てが、「とにかく機能する（Just Works）」。（ 『8.2.1.3 一貫性を保て』）
一貫性のあるコードベースを目指すことで、（中略）コードとそれに対して作業するエンジニアの双方についてほぼ制約のない流動性が与えられ、長期保守に必要なプロセスが簡略される。（『8.2.1.4 一貫性の優位性』）
という考え方がベースにあるようです。この『8章 スタイルガイドとルール』にて、技術スタックに留まらず、コードの書き方（スタイルガイド）のレベルでも極力統一することを目指している旨が書かれています。
Google社内の標準言語としてTypeScriptが承認される。ng-conf 2017 － Publickey
考えてみれば、Googleが標準言語を定めていることは有名ですし、人員がどれだけ入れ替わっても影響を最小化する方法は何か？異動したエンジニアが最速でオンボーディングするにはどうすれば良いか？と合理性を突き詰めた結果、各要素の徹底した統一に至ったと考えると頷ける気がしました。
もっとも、同じ8章にて、情勢にあわせてルールは変更していくし、例外もあり、現実問題に譲歩することもある、といった記載があります。スタイルガイドに主に焦点が当たっている章ではありますが、技術選定についてもこれに準ずるのかな？と思いました。
他のBigTechはどうなんでしょうね？
ソニックガーデン社: Rails+AWSで統一 （2016時点情報）
ソニックガーデン倉貫さんの『納品をなくせばうまくいく』（2016）『5章 02「納品のない受託開発」を支える技術戦略』にて、「扱う技術をプロジェクトごとに選定」すると、「会社内でのノウハウ共有も、社員同士の助け合いも難しくな」る懸念について述べています。それを理由として、以下を社内の「推奨技術」にしている旨が記載されています。
- 言語: Ruby
- フレームワーク: Ruby on Rails
- クラウド: AWS or Heroku
- OS: Linux
一方で以下のようにも述べています。
ただし、この推奨技術は時代とともに変化していきます。そうしたトレンドに先駆けて新しい技術を取り込む姿勢は必要ですし、常に効率のよいソフトウェア開発を実現するために、新技術のリサーチや習得を怠らないようにしています。
このへんはGoogle社の変更ルールにも通じていきそうです。
DMM社: Goで統一 (2022時点情報)
DMM.go #4「マイクロサービスプラットフォーム向け負荷試験基盤の初期リリースを終えた話」イベントレポート - DMM inside
負荷試験基盤に焦点が当たった記事ですが、社内的にGo言語に統一していく旨の記述があったため着目していきます。
これは負荷試験基盤をつくった理由でも説明した通り、各チームがそれぞれ独自の技術選定をしていると、チーム間でノウハウの共有ができません。負荷試験に限らず今までのDMMでは各チームで独自の技術選定をしていた課題があったので、組織戦略として開発言語にGoを採用しました。 開発言語をGoに統一することで、負荷試験に限らずさまざまな用途で共通の仕組みを作りチーム間のノウハウの共有を目指すことができます。
こちらもGoogle社やソニックガーデン社の動機と似ているように感じますね。また、ソニックガーデン社もDMM社も「戦略」という言葉を使って技術選定を統一している点が興味深いです。
Ubie社: GoとNode.jsで統一 (2022時点情報)
これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。（中略）そのため、これからは技術スタックを収束させていくこととし、その選定を行いました。
として、Node.js、Goに寄せていく旨が書かれています。上記記事では2言語の選定理由も詳しく書かれているので、興味のある方は読んでみてください。
一方で、以下のように例外を認める例も示しています。
ただしこれはあくまで原則で、合理的理由がある場合には他の言語も採用します。例えば、機械学習をやるサービスには Python を使うなどが考えられます。
まとめ
4つほどの事例に目を通した結果、技術スタックを統一する目的として、
- 人材流動性を高めたい（属人性の低減）
- ノウハウをチーム間で共有したい
- 生産性を高めたい
といった点があるように思いました。
一方で、時流や前提条件の変化に対応するため、一度決めた技術スタックを絶対視せず、常に見直し続ける必要があるといった但し書きも見られました（ここがかなり重要な気がします）。
自分の感想としては、組織として属人性を最小化し、かつ生産性の最大化を狙う場合に技術スタック統一をしていく、というのは非常にアリと思いました。技術選定が常に全社に対して影響のある意思決定になるため、選定した技術が与えるポジティブな影響は増大すると思います。ただ必然的に、逆の場合もネガティブ影響が非常に大きくなってしまうと思われるため、より技術選定に慎重になるべきでしょう。技術選定に絶対的な正解はありませんが、「まずい選定」というのはあるんじゃないかと思っていて、それをうっかり引いてしまうとエンジニア採用をはじめ、プロダクト品質、開発生産性に大きくマイナスに響いてしまうおそれもあるため、もしそうなった場合はすぐに軌道修正を図る必要がありそうです。
本記事がみなさんの技術選定の一助となれば幸いです。ではでは。
